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(57) Abstract 

The present invention is a transport layer protocol for data packet 
delivery in a wireless environment. The method of the present invention 
incorporates a transport data protocol structure to implement a modified 
go-back-n automatic repeat request for data packet delivery. The 
invention further employs a distinct pair of sequence numbers and 
request numbers for client and server originated data packet transmissions. 
Several packets can be transmitted by the sender without the need for 
each packet to be individually acknowledged by the receiver. After n 
successive packets have been transmitted, the sender polls the receiver 
for an acknowledgment. The acknowledgment (350) sent by the receiving 
party contains the request number equal to the sequence number of the 
packet that the receiver requests to be sent next (325). This number 
represents the last packet which was received in order plus one (325). 
Lastly, the present invention provides a method for the client and server, 
to imply that an acknowledgment (350) has been sent to it even though 
the acknowledgement was lost in transmission. 
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METHOD FOR IMPLEMENTING A TRANSPORT LAYER 
PROTOCOL FOR WIRELESS PACKET DATA DELIVERY 

BACKGROUND OF THE INVENTION 
5 Technic al Fiel d of the Invention 

The present invention pertains in general to a 
. transport layer protocol and more particularly, to a 
method for implementing a modified go-back-n automatic 
repeat request protocol in the transport layer for 
10 wireless packet data delivery. 

Descript ion of Related Art 

The International Standards Organization (ISO) has 
established a seven layer model regarding communication 
protocols. The forth layer of this model is referred to 
15 as the transport layer and is responsible for packet data 

delivery between a client and a server. To date, the vast 
majority of communication using packet data delivery has 
occurred via a wireline link. A standard solution for 
providing reliable packet data delivery in the wired 
20 environment is the use of Transport Control Protocol 

(TCP) . Transport Control Protocol was designed for wired 
environments characterized by relatively reliable physical 
connections between communication devices having large 
memories and computing power. 
25 For various known reasons Transport Control Protocol 

is unsuited for the harsh environment of wireless packet 
switched networks. For example, Transport Control 
Protocol requires a large memory to store both the 
software for implementing the Transport Control Protocol 
30 and the numerous data packets necessary for implementing 
the Transport Control Protocol's automatic repeat request 
methodology which allows for the receipt of out-of-order 
packets. Wireless communication, however, is 

characterized by the use of radios with small memories and 
35 limited computing power as compared to the wired 

environment. A further problem related to the use of 
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The present invention provides for a separate and 
distinct pair of sequence numbers and request numbers for 
client originated data transmissions and server originated 
data transmissions. Thus, for client originated data 
5 transmissions, the client sequentially numbers transmitted 

data packets with one set of sequence numbers and the 
server responds with request numbers equal to the sequence 
number of the data packet next expected to be sent . 
Conversely, for server originated data transmissions, the 

10 server sequentially numbers transmitted data packets with 

another set of sequence numbers distinct from client 
originated transmissions and the server responds with 
request numbers equal to the sequence number of the data 
packet next expected to be sent . 

15 The present invention further provides a method for 

the client and server to imply that an acknowledgment has 
been sent even though the acknowledgment may have been 
lost in transmission. The client and server imply an 
acknowledgment if a subsequent . packet is received having 

20 ' an expected sequence number. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the method of the 
present invention may be, acquired by reference to the 
25 following Detailed Description when taken in conjunction 

with the accompanying Drawings wherein: 

Figure 1 is a Transport'. Protocol Data Unit for 
implementing the present invention; 

Figure 2 is a sequence diagram for . initiating a 
30 communication session; 

Figure 3 is a flow diagram for implementing the go- 
back-n automatic repeat request method of the present 
invention; 

Figure 4 is a sequence diagram for transmitting data 
35 from a client to a server without the loss of any data; 

Figure 5 is a sequence, diagram for transmitting data 
from a client to a server when a packet of data is lost; 
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receiver sends an acknowledgment, to the sender. T h e 
fifth byte of the TPDU 100 comprises either the most 
significant eight bits of a session ID 181 or an eight bit 
value representing a retry time 182. During an 

5 initialization command sent by a client to a server the 

session ID has not yet been defined and the fifth byte of 
the TPDU 100 contains an eight bit value informing the 
server of the initial retry timeout value. This value has 
a five second resolution making the initial* retry time in 
10 seconds equal to five times the value provided in this 

field. Upon receiving the initialization command,, the 
server sends an acknowledgment to the client containing 
the most significant eight bits of the session ID 181 in 
the fifth byte and the least significant eight bits of- the 
15 session ID 183 contained in the sixth byte of the TPDU 

100. The most significant eight bits of the session ID 
181 together with the least significant eight bits of the 
session ID 183 comprise a sixteen bit value identifying 
the current communication session between the client and 
20 the server. All TPDUs transmitted between the client and 

the server must contain the session identifier, otherwise, 
the data will be ignored. 

The seventh and eighth byte of the TPDU 10 0 comprises 
the sequence number 180 and the" ninth and tenth byte of 
25 the TPDU 100 comprises the request number 190. Every TPDU 

contains a unique sequence number identifying that 
particular TPDU 100. 'When a communication session between 
a client and a server is set up, numbers based on the 
current time of day are selected for client originated 
30 sequence number 180 and for the server originated sequence 

number which is communicated to the server via the request 
number 190. For the duration of the communication 
session, each TPDU 100 is identified with sequentially 
increasing sequence numbers 180. 
35 The last two bytes of the TPDU 100 forming the 

trailer 120 contain a sixteen bit cyclic redundancy check 
for the TPDU 10 0 . 
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a previously, correctly received TPDU. If the sequence 
number 180 of the TPDU does not match the expected 
sequence number, the receiving party discards the received 
packet (step 320) . If, on the other hand, the sequence 
number 180 of the TPDU matches the expected sequence 
number the receiving party increments the expected 
sequence number (step 325) and performs an operation on 
the TPDU (step 33 0) in accordance with the command 
contained in the TPDU field 140. After the receiving 
party has operated on the data (step 330) , or discarded 
a packet containing a sequence number 18 0 other than the 
expected sequence number (step 32 0) the receiving party 
determines whether the pole bit 170 is set on the received 
TPDU (step 340). If the pole bit 170 is not set the 
receiving party returns to continue monitoring for further 
transmitted packets (step 300) . If , on the other hand, • 
the pole bit 170 is set, the receiving party sends an 
acknowledgment (step 3 50) to. the sending party, and then 
returns to continue monitoring for transmitted packets 
(step 3 00) . The acknowledgment sent by the receiving 
party contains the request number 190 equal to the 
sequence number 180 of the, packet that the receiver 
requests to be sent next . This number represents the last 
packet which was received in order plus one . The method 
described in the flow diagram of Figure 3 applies equally 
both to client and server . originated transmissions. 

Referring additionally now to Figure 4, there is 
illustrated a sequence diagram for transmitting data from 
a client 200 to a server 210 when no data packets have 
been lost. After a communication session has been 
established, the client 20 0 proceeds to transmit data 
packets to the server 210. The number of packets p which 
the client 200 transmits to the server 210 before 
requesting an acknowledgment is set by the user. The 
client 200 transmits multiple data packets to the server 
210 and eventually the client 200 transmits the p-1 data 
packet 4 00 having a sequence number 180 of a. Since one 
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Ref erring additionally now to Figure 6, there is 
illustrated a sequence diagram for transmitting data from 
a server 210 to a client 200. This diagram includes 
server 210 originated data transmissions and illustrates 
5 the distinction between sequence numbers 180 and request 

numbers 190 associated with client 200 originated and 
server 210 originated transmissions . 

The client 200 initiates a communication session by- 
transmitting an . initialization TPDU 600. The 
0 initialization TPDU 600 contains a randomly generated 

sequence number 180 of y for client 200 originated 
transmissions and a time based request number 190 of z 
corresponding to server 210 originated transmissions. The 
server 210 upon receiving the initialization TPDU 6 00 
5 transmits an acknowledgment TPDU 610 containing a request 

number 190 of- y+1 . Upon receiving the acknowledgment TPDU 
610 the client 200 transmits a data request TPDU 620 in 
which the pole bit 170 is set thereby requesting an 
acknowledgment. Since this TPDU 620 is a client 200 
:0 originated TPDU the sequence number 180 is equal to the 

sequence number y of the previously transmitted TPDU 60 0 
plus 1 or y+1. The data request TPDU 620 also includes 
a request number 190 of z which is the sequence number 180 
which the server 210 will use to begin data transmission. 
25 Upon receiving the data request 620 the server 610 
transmits an acknowledgment TPDU 630 having a request 
number 190 of y+2. The server 210 then begins to transmit 
the requested data with server "210 originated TPDU 
transmissions. These transmissions have sequence numbers 
30 180 beginning with z as requested by the client. A data 

TPDU 64 0 having a sequence number 180 of z and a request 
number 190 of y+2 is thus transmitted to the client 200 
with the pole bit 170 set to request acknowledgment . The 
data TPDU 640 also contains the client 200 requested data. 
35 Upon receiving the data TPDU 640 the client 200 transmits 
an acknowledgment TPDU 650 having a request number 190 of 
z+1 equal to the next server 210 originated packet 
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request number y+2 of the data . TPDU 720 contains the 
appropriate request number 190 and implies that an 
acknowledgment TPDU 710 has been sent by the server 210. 
The client 200 , therefore, retains the data TPDU 720 and 
transmits an acknowledgment 730 having a request number 
190 equal to z+1 to the server 210. In a similar fashion, 
this acknowledgment TPDU 73 0 may be unsuccessfully 
received by the server 210. Nevertheless, the client 200 
transmits another TPDU, which for this example is data 
TPDU 740 having a sequence number 180 equal to y+2 and 
a request number 190 equal to z + 1. The server 210, 
following the methodology of the present invention, 
recognizes that the request number z + 1 is the appropriate 
request number 190 and implies that the client 200 has 
transmitted the acknowledgment TPDU 73 0 even though it was 
not received by the server 210, The stipulation of- 
implying an acknowledgment if a packet is subseiquently 
received which has the expected request number 190 
prevents the client 200 and the server 210 from becoming 
out of synchronization with one another and constantly re- 
sending data packets to one another. 

Unlike Transport Control Protocol, the transport 
layer protocol of the present invention does not support 
a selective automatic repeat request methodology and thus, 
does not support the receipt of out of order packets. In 
the present invention, packets received out of order are 
discarded. If, however, a packet is received out of order 
but contains a request for acknowledgment , an 
acknowledgment is sent containing the request number equal 
to the sequence number of the last packet received in 
order plus one . 

Although a preferred embodiment of the method of the 
present invention has been illustrated in the accompanying 
Drawings and described in the foregoing Detailed 
Description, it is understood that the invention is not 
limited to the embodiment disclosed, but is capable of 
numerous rearrangements, modifications and substitutions 
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WHAT IS CLAIMED IS: 

1. A Transport Protocol Data Unit for a wireless 
packet data delivery comprising: 

a response bit for signifying the Transport 
5 Protocol Data Unit as a command or response Transport 

Protocol Data Unit ; 

a poll bit for requesting an acknowledgment ; 
a sequence number field for identifying the 
Transport Protocol Data Unit; and 
10 a request number field for communicating a 

sequence number of the Transport Protocol Data Unit 
requested to be next transmitted. 

2. A method for data packet delivery between a 
sender and a receiver, comprising the steps of: 

15 transmitting a user selected number of data 

packets, wherein each packet is sequentially numbered and 
each packet except for a last packet has a poll bit 
cleared, the last packet having the poll bit set; 

receiving the data packets transmitted by the 

20 sender; 

detecting the sequence number and the poll bit 
of each received packet; 

comparing the sequence number of each received 
packet against an expected sequence number; 
25 storing data contained within packets when the 

sequence number of the packet matches the expected 
sequence number ; otherwise 

discarding the data packets. 
3. A method for data packet delivery between a 
30 sender and a receiver, comprising the steps of: 

transmitting a user selected number of data 
packets, wherein each packet is sequentially numbered and 
each packet except for a last packet has a poll bit 
cleared, the last packet having the poll bit set; 
35 receiving the data packets transmitted by the 

sender; 
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